Routing on isLegacyRequest from a plain Node (req, res) handler currently means hand-building a
globalThis.Request out of req.headers:

const probe = new globalThis.Request(`http://localhost${req.url}`, {
    method: req.method,
    headers: req.headers as Record<string, string>
});
await ((await isLegacyRequest(probe, req.body)) ? legacy(req, res) : modern(req, res, req.body));

That's a smell. toNodeHandler already contains the correct conversion (header arrays, HTTP/2
pseudo-headers, the parsed-body re-serialization) as a private helper — users just can't reach it. It also
nudges people toward the two-argument isLegacyRequest(probe, body), which reads as if the second argument
were required. It isn't: the predicate clones internally, so isLegacyRequest(request) is the whole API.
Our own examples taught the same two-argument pattern, each behind ~16 lines of buffer-read + JSON.parse +
hand-built Request.

This exports the conversion as toWebRequest() and moves both examples onto it. The Express one
(legacy-routing) becomes:

import { toWebRequest } from '@modelcontextprotocol/node';

// Express — the body parser already consumed the stream, so pass it along.
const probe = await toWebRequest(req, req.body);
await ((await isLegacyRequest(probe)) ? handleLegacy(req, res) : modernNode(req, res, req.body));

and the plain node:http one (elicitation):

// toWebRequest reads the stream once, so the body now lives in `request`.
// The predicate runs first: it classifies an internal clone, leaving
// `request` readable for the .json() both arms need.
const request = await toWebRequest(req);
const legacy = await isLegacyRequest(request);
const body: unknown = req.method === 'POST' ? await request.json().catch(() => {}) : undefined;
await (legacy ? handleLegacy(req, res, body) : modern(req, res, body));

How:

• toWebRequest(req, parsedBody?, options?) is the existing private conversion, exported. The function body
  is unchanged, and toNodeHandler now calls it with the abort signal in the options bag instead of a
  positional argument, so the adapter's behavior is identical.
• It returns Promise<Request> (it reads the Node stream). Pass parsedBody when a body parser already
  consumed the stream — it's re-serialized as the Request body and the entity headers are rewritten. Pass
  options.signal to tie the constructed request to client disconnect, the way toNodeHandler does.
• isLegacyRequest's docs now lead with the single-argument form and present parsedBody as the perf
  escape hatch it is, not a required companion.

Motivation and Context

isLegacyRequest takes a web-standard Request, but the Node hosting path only has an IncomingMessage.
The conversion between the two already existed inside toNodeHandler; exporting it removes the last reason
to build a globalThis.Request by hand — including in our own examples, which are what people copy.

How Has This Been Tested?

New unit tests in packages/middleware/node/test/toWebRequest.test.ts cover the stream-read and
parsedBody body paths (the latter asserts the Node stream is never touched), the Host-derived URL, header
copying (multi-valued append, HTTP/2 pseudo-header skipping), the signal option, and the clone-readability
contract isLegacyRequest relies on. The existing toNodeHandler suite passes unchanged, which is the
no-behavior-change check for the adapter path. The full example e2e suite passes (both rewritten stories
across all their transport × era legs), along with typecheck:all, lint, and the docs build.

Breaking Changes

None. New export; toNodeHandler behavior is unchanged; the isLegacyRequest change is documentation only;
the examples route every input express.json() parses identically.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

One edge worth naming: for a POST express.json() doesn't parse (a non-JSON content type — not valid MCP),
body-parser 2.x leaves req.body undefined and the Node stream unread, so toWebRequest reads it and the
predicate classifies the real bytes (the old hand-built, header-only probe never saw that body at all). Not
meaningful for spec traffic, and the old code already routed it differently between Express 4 and 5 (an
unparsed body is {} on 4 but undefined on 5, and the two classify differently).

One deliberate nuance: the example's predicate now reads the body through the same TextDecoder path the
entry itself uses, where the old hand-rolled read used Buffer#toString('utf8'). The only observable
difference is a leading UTF-8 BOM, which the old read left in (so JSON.parse failed and the request fell
to the legacy arm) and is now stripped, so the body classifies on its content.

The only other Request construction in examples/ is authServer.ts's
new Request(new URL(req.originalUrl, issuer)), which is left alone on purpose: it synthesizes an OAuth
discovery URL from issuer, not a faithful conversion of the inbound request, so toWebRequest would
change it.

@modelcontextprotocol/node README and changeset included. isLegacyRequest's rewritten docs are precise
about the one case parsedBody is needed rather than just faster: a Request whose own body was already
read (the internal clone would throw). Behind a body parser the right fix is toWebRequest(req, req.body)
— the predicate still takes one argument.